• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The present invention relates to a method of exchange of keys between peers, of the Diffie-Hellmann type, authenticated by means of a chain of transaction blocks. The public keys of the peers are registered in the distributed register by means of transactions emitted by the peers, the latter being identified by their addresses of portfolios and authenticated by their respective signatures.
    公开号:FR3076422A1
    申请号:FR1763393
    申请日:2017-12-29
    公开日:2019-07-05
    发明作者:Christine Hennebert
    申请人:Commissariat a lEnergie Atomique CEA；Commissariat a lEnergie Atomique et aux Energies Alternatives CEA；
    IPC主号:
    专利说明:

    AUTHENTICATED KEY EXCHANGE METHOD BY BLOCK CHAIN
    DESCRIPTION
    TECHNICAL AREA
    The present invention relates generally to cryptography and more particularly to the generation of a secure channel between peers by means of a secret key. It also relates to the blockchain technique.
    PRIOR STATE OF THE ART
    The generation of a secure channel in remote devices, also called “peers” in the following, supposes the sharing of a secret key between these devices. This sharing can be achieved by manual distribution of keys, prior to any communication on the channel, or by means of a Diffie-Hellmann type key exchange protocol using an asymmetric cryptosystem. It is recalled that, in a Diffie-Hellman type key exchange protocol, each remote device has a pair of asymmetric keys (private key, public key). The private key of a sending device is kept secret by the latter and is in particular never disclosed to the receiving device. It is used to encrypt or sign messages and to identify the sending device. On the other hand, the public key is known to the recipient device and is used to decrypt messages or to verify the signature of the sending device. The purpose of the key exchange protocol is to allow, from public elements of a cryptosystem exchanged on an insecure channel, each remote device to independently calculate the same secret key which will be used to establish a secure channel between them .
    When the cryptosystem is based on an elliptic curve e (f) defined on a finite field F and characterized by the domain parameters (q, a, b, G, n, h) where q is the number of elements of the body, a, b are the parameters of the elliptic curve, G is a, Iwl point generator, n is the order of G in the additive group EfF), h ------- 1 is the n
    cofactor of G in this group, is the order of group E (Ffi. Each remote device can choose a private key sk from among the integers [l, n-1], the corresponding public key being given by the coordinates of the point Pk = It is recalled that searching for .if starting from Pk amounts to searching for a solution to the ECLDP problem (Elliptic Curve Discrete Logarithm Problem), currently impossible to solve in polynomial time.
    If Alice and Bob are the two peers corresponding to the two remote devices, a Diffie-Hellmann key exchange protocol using an elliptical cryptosystem (ECDH protocol) can be described by the following steps:
    Alice chooses an integer a which will remain secret, calculates the ephemeral public key, P a = aG, and transmits it to Bob.
    Similarly, Bob chooses an integer b which will remain secret, calculates the ephemeral public key, P b = bG, and transmits it to Alice.
    When P b is received , Alice calculates aP b = ab.G.
    On receiving P a , Bob calculates bP a = ba.G.
    Alice and Bob now share a secret element consisting of a point on the elliptical curve, ab.G. They can for example apply a hash function, previously agreed between them, to one of the coordinates of the point in question to obtain a symmetric session key with which they encrypt the data on the channel.
    An important limitation of the above key exchange protocol is that it is not immune to a Man-ln-the-Middle attack. Indeed, an attacker, Eve, can intervene between Alice and Bob, make Alice believe that she is trading with Bob and Bob that he is trading with Alice. By implementing the protocol described above, Eve chooses a first integer x and shares a first secret element axG with Alice, then chooses a second integer y and shares a second secret element byG with Bob. Eve can thus create a first secure channel with Alice and a second secure channel with Bob. When Alice believes she is transmitting data securely to Bob, she is actually providing it to Eve. Conversely, when Bob believes he is transmitting data securely to Alice, he is in fact also transmitting it to Eve.
    A known solution to remedy this type of attack is to identify the issuer of each public key. Thus, Alice transmits to Bob not only her ephemeral public key P a = aG but also a digital signature of P a , signed with her private key (for example by means of an ECDSA algorithm). Bob must then have Alice's public key to verify the signature in question. If the verification is positive, it means that the ephemeral public key was indeed issued by Alice and not a third party. Of course, conversely, Bob transmits to Alice his ephemeral public key P b = bG accompanied by the signature of P b by means of Bob's private key, and Alice proceeds to verify this signature using the public key of Bob to authenticate the origin of the ephemeral public key.
    This solution is however only partially satisfactory insofar as the transmission of the public key from Alice to Bob (or that from Bob to Alice) on an insecure channel is itself likely to be the subject of a "Man-in-theMiddle" attack. In order to link the public key of an issuer with its identity, we use a digital certificate (in X.509 format or implicit certificate, for example) issued by a certification authority. As a result, the Diffie-Hellman protocol requires the presence of a trusted third party to be robust to “Man-in-theMiddle” attacks.
    In order to avoid resorting to a trusted third party and in particular to a centralized certification authority, it was proposed in the article by P. McCorry et al. entitled “Authenticated key exchange over Bitcoin”, published in 2015 in Chen L., Matsuo S. (eds) Security Standardization Research. Lecture Notes in Computer Science, vol 9497. Springer, to use a peer identification technique based on the properties of the Bitcoin blockchain. It is recalled that a block chain is a distributed and secure register of all the transactions carried out since the chain was started. A complete introduction to the Bitcoin blockchain can be found in the work by A.M. Antonopoulos entitled "Mastering Bitcoin" published in 2015 by O'Reilly editions.
    Fig. 1 represents a key exchange method authenticated by a blockchain as described in the above-mentioned article.
    Before exchanging keys, we assume that Alice and Bob each independently generated a private key (noted a for Alice and b for Bob) and, from the corresponding public key (P a = aG for Alice and P b = bG for Bob), by hash, an ephemeral wallet address (noted @wallet_a Alice for Alice and @wallet_b Bob for Bob). Ephemeral addresses will only be used for transactions supporting this exchange. The respective portfolios of Bob and Alice are also assumed to be credited with sufficient cryptocurrency.
    Alice forms in 110 a transaction T a and this is broadcast to the nodes of the Bitcoin network. After being validated, incorporated into a block and confirmed by mining, it becomes part of the distributed ledger. Similarly, Bob forms in 120 a transaction T b and this is broadcast step by step to the nodes of the network.
    Generally, a transaction represents a transfer of cryptocurrency units from one entry (or several entries) to one exit (or to several exits). A transaction is denominated in terms of UTXO (Unspent Transaction Output), each UTXO representing an amount not spent by its owner and being locked by a locking script. To be able to spend a UTXO, the owner must identify himself by presenting cryptographic elements to the UTXO (generally the public key and a signature generated from the corresponding private key) in the form of an unlocking script. If the items presented in the unlock script meet the conditions specified in the lock script, the transaction is committed. Note that in Bitcoin, the most commonly used unlock script is Pay-to-Public-Key-Hash (P2PKH) and the lock script is scriptSig.
    The transaction T a formed by Alice includes as input a reference to a UTXO held at the wallet address @wallet_a Alice as well as an unlocking script (represented by a key in the figure). This unlock script contains the ephemeral public key of Alice, P a and a signature of this public key (more precisely of the transaction in which the public key P a is substituted for the unlock script, the transaction then being doubly hashed) at using the corresponding private key, a.
    The transaction T a includes as output the recipient's wallet address (Bob), i.e. @wallet_b Bob as well as a locking script (represented by a padlock in the figure) that Bob can unlock by providing, via an unlocking script , the cryptographic elements (public key and signature) satisfying the conditions set in the locking script. This transaction output creates a UTXO (@wallet_b Bobmontant) at Bob's ephemeral wallet address. Alice's ephemeral wallet address was also indicated at the output so that Alice could recover the balance of the transaction from her wallet (creation of a UTXO in Alice's ephemeral wallet).
    Similarly, the transaction T b includes as input a reference to a UTXO held at the wallet address @wallet_b Bob, as well as an unlocking script containing the ephemeral public key of Bob, P b , and a signature of this public key using the corresponding private key b.
    At the exit, the transaction T b includes at the exit the ephemeral wallet address of Alice @wallet_a Alice as well as a locking script (symbolized by a padlock) that Alice can unlock by providing the cryptographic elements satisfying the conditions set in the lock script. This output creates a UTXO (@wallet_a Alicemontant) to Alice's ephemeral wallet address. A second exit is planned to recover the balance in the form of a UTXO at Bob's ephemeral wallet address.
    The amounts of UTXO @wallet_a Alice-amount and @wallet_b Bob-amount can be chosen equal to balance the exchange.
    Once the transactions T a and T b have been validated, recorded in the block chain and confirmed by mining, Alice (resp. Bob) scans the distributed register in search of the transaction sent by Bob (resp. Alice). Alice retrieves in the entry part of T b the ephemeral public key P b from Bob and, conversely, Bob recovers in the entry part of T a the ephemeral public key P a from Alice. Alice then calculates aP b = abG and Bob bP a = baG: Alice and Bob therefore have the shared secret key abG.
    The auditability of the distributed register allows all users (nodes) to verify that the ephemeral public keys used in this exchange have never been used before, that the public key P a belongs to Alice (more precisely is linked to the Alice's ephemeral wallet address) and that the public key P b belongs to Bob (more precisely is linked to Bob's ephemeral wallet address). Thus, the exchange of keys between Alice and Bob can be authenticated by the blockchain, without the intervention of a trusted third party.
    However, the systematic generation of ephemeral wallet addresses at each key exchange can prove to be complicated to manage and costly in terms of computing resources for the remote devices hosting these wallets.
    An object of the present invention is therefore to propose a method of exchanging keys between peers, authenticated by blockchain and therefore without recourse to a trusted third party, and which does not require the generation of ephemeral portfolios.
    STATEMENT OF THE INVENTION
    The present invention is defined by a method of exchanging keys between a first user and a second user of a chain of transaction blocks, each user having a wallet address enabling him to send and receive transactions, said method comprising the following steps:
    the first user generates a first ephemeral private key (a) and a first ephemeral public key (corresponding PJ by means of an asymmetric cryptosystem;
    the first user forms and issues a first transaction (TJ whose entry refers to a first UTXO held at the wallet address of the first user and whose exit creates a second UTXO in the wallet of the second user, the exit from the first transaction further comprising a script for registering the first ephemeral public key (P a ) in the block chain;
    the second user scans the block chain and accesses the first transaction, after it has been confirmed by a mining of the block which contains it;
    the second user verifies from the entry of the first transaction that it has been issued by the address of the wallet of the first user and, if so, reads on the output of the first transaction the first public key ephemeral (^);
    the second user generates a second ephemeral private key (b) and second a corresponding ephemeral public key (P b ) using said asymmetric cryptosystem;
    the second user forms and issues a second transaction (T B ) whose input refers to a third UTXO held at the wallet address of the second user and whose output creates a fourth UTXO pointing to the portfolio of the first user, the output of the second transaction further comprising a script for registering the second ephemeral public key in the block chain;
    the first user scans the blockchain and accesses the second transaction, after it has been confirmed by a mining of the block which contains it;
    the first user verifies from the entry of the second transaction that it has indeed been issued by the address of the wallet of the second user and reads on the output of the second transaction the second ephemeral public key (P b );
    the first user calculates the product of the first ephemeral private key (a) with the second ephemeral public key (P b ) and the second user calculates (280) the product of the second ephemeral private key (b) with the first ephemeral public key (P a ) to generate a common secret key (k ab ).
    Advantageously:
    the first transaction contains as input an unlocking script comprising the public key associated with the wallet address of the first user as well as a digital signature of this public key by means of the first ephemeral private key;
    - The second transaction contains as input an unlocking script comprising the public key associated with the wallet address of the second user as well as a digital signature of this public key by means of the second ephemeral private key.
    The asymmetric cryptosystem is preferably a cryptosystem on an elliptical curve.
    The blockchain is typically Bitcoin and the script for recording the first and second transactions contains an OP_RETURN operation, the first and second ephemeral public keys being stored by the recording script in compressed form in the blockchain.
    Alternatively, the first and second transactions comprise as output a second recording script, the recording script and the second recording script containing OP_RETURN operations, the first and second ephemeral public keys being respectively stored by the recording script and the second script to record in full form in the blockchain.
    The amounts of the first and third UTXO can be identical.
    BRIEF DESCRIPTION OF THE DRAWINGS
    Other characteristics and advantages of the invention will appear on reading a preferred embodiment of the invention, made with reference to the attached figures among which:
    Fig. 1, already described, schematically represents an exchange of keys between peers, authenticated by a block chain, according to a method known from the state of the art;
    Fig. 2 schematically represents an exchange of keys between peers, authenticated by a block chain, according to an embodiment of the invention.
    DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS
    We first consider a chain of transaction blocks of type
    Bitcoin, as described in the introductory part and will again consider a key exchange between two users of the blockchain, Alice and Bob. As we will see later, this exchange of keys can be generalized to a multilateral exchange between peers. Each user is equipped with a communication device embedding a blockchain client, either a thin client (for example for a smartphone), or a complete client (the device is then a “complete” node, it has a complete copy of the shared register ). Each user has a wallet address that allows them to send and receive transactions and messages.
    Prior to exchanging keys, Alice and Bob exchange their wallet addresses, for example in digital form or in the form of QR code. The address of Alice's portfolio is noted @wallet_Alice and that of Bob's portfolio, @wallet_Bob.
    Fig. 2 schematically describes a key exchange method according to a first embodiment of the invention.
    In a first step, 210, a first user (or first peer), Alice generates a private key a and the corresponding public key, P a = aG where G is the generating point of a cryptosystem on an elliptical curve, for example the cryptosystem on the Koblitz curve secp256kl used in Bitcoin to generate wallet addresses. The key P a is an ephemeral public key insofar as it will only be used for the exchange of keys between Alice and Bob.
    The private key can be generated randomly (so-called nondeterministic key portfolio) or else deterministically from a seed (so-called hierarchical deterministic key portfolio) in a manner known per se.
    In step 220, Alice forms a transaction T A comprising as input a reference to a UTXO (recorded in the block chain and held at the wallet address @wallet_Alice) as well as an unlocking script (symbolized in the figure by a key). This unlocking script contains the public key P a corresponding to Alice's wallet address @wallet_Alice as well as a signature of Alice's public key (more precisely of the transaction in which the public key P a is substituted for unlock script, the transaction then being doubly hashed) using his private key.
    The unlock script allows Alice to spend the assets contained in the UTXO in question.
    On a first exit, the transaction T A includes the wallet address of the recipient (second user or second peer), Bob, i.e. @wallet_Bob, the amount agreed for this transaction, in other words the amount of UTXO created at this address (@ wallet_Bob-jamb), all protected by a locking script (padlock shown in the figure). Bob will be able to unlock the UTXO created by this output by presenting the cryptographic elements required by the locking script (Bob's public key and his signature) to verify his identity (more precisely the association between the wallet address @wallet_Bob and the public key).
    Optionally, on a second exit, the transaction T A includes as an exit the address of Alice's wallet to receive the balance of the transaction, if the amount that Alice has as an entry (appearing in the UTXO at the address of the wallet 'Alice) is greater than the amount sent to Bob (i.e. the amount in UTXO created at Bob's wallet address).
    On a third output, the transaction T A comprises at least one script for recording data in the block chain, OP_RETURN <data>. The operator OP_RETURN creates a “provably unspendable” entity which is not stored with the UTXOs. Unlike a UTXO, the entity thus created cannot then be spent by means of an unlocking script.
    In the transaction T A , the data of the script OP_RETURN correspond to the ephemeral public key P a in compressed form or in complete form. In Bitcoin, the OP_RETURN operation stores up to 40 bytes in the blockchain. A public key obtained with an elliptical cryptosystem on a secp256ll curve can be stored in compressed form on 32 bytes. If an additional OP_RETURN script is used, it will be possible to store up to 80 bytes which will make it possible to store the ephemeral key P a in complete form (64 bytes).
    Once the transaction T A has been validated, recorded in the block chain and confirmed, the amount agreed between Alice and Bob, corresponding to the UTXO created on the first exit from T A , is credited to Bob's wallet.
    When Bob receives confirmation of this amount, he scans the blockchain register at 230 to view the corresponding transaction. In the case of the Bitcoin blockchain, it can for example use the blockchain.info or block explorer command to view the transaction.
    After having found the transaction, Bob reads on his entry the address of Alice's wallet at the origin of the transaction and compares it to the address that Alice had previously given him (for example by means of a QR code) . He can thus ensure that these addresses are the same. Bob then reads on the third and, if applicable, the fourth exit (s) of the transaction, the value of the ephemeral public key P a .
    In step 240, Bob generates a private key b (for example from a seed) and the corresponding public key P b = bG using the same cryptosystem on an elliptical curve as that used by Alice.
    In step 250, Bob forms a transaction T B in the same way as Alice previously. In other words, Bob supplies the entry of the transaction, in an unlocking script (for example P2PKH in Bitcoin), the cryptographic elements (Bob's public key and signature by his private key) necessary to unlock the locking script locking the UTXO as the first exit from the transaction.
    The first exit from transaction T B includes Alice's wallet address, @wallet_Alice, the agreed amount donated to Alice, all protected by a locking script (P2PKH for example). Alice will be able to unlock the UTXO created by this output by presenting the cryptographic elements required by the locking script (Bob's public key and his signature).
    Optionally, on a second exit, the transaction T B includes as an exit the address of the wallet of Bob to receive the balance of the transaction, if the amount that Bob has in entry is higher than the amount sent to Alice.
    Advantageously, on a third output, the transaction T B comprises at least one script for recording data in the block chain, OP_RETURN <data>, where the data correspond to the ephemeral public key P b in compressed form or in complete form . As already mentioned above, the OP_RETURN <data> script in Bitcoin can store 40 bytes. An additional data recording script makes it possible to store 80 bytes and therefore the key P b in complete form.
    Once the transaction T B validated, recorded and confirmed, the amount agreed between Alice and Bob, corresponding to the UTXO created on the first exit of T B , is credited in the wallet of Bob.
    When Alice receives confirmation of this amount, she scans the blockchain register at 260 to view the corresponding transaction (using for example the command blockchain.info or block explorer when the blockchain is Bitcoin).
    When Alice has found the transaction, Alice reads on her entry the address of the wallet of Bob at the origin of the transaction and compares it to the address that Bob had previously provided. It thus ensures that these addresses are the same. Alice then reads, on the third and, if applicable, the fourth exit (s) from the transaction, the value of Bob's ephemeral public key, P b .
    In step 280, Alice calculates, from Bob's ephemeral public key, the secret key aP b = abG. Bob does the same using Alice's ephemeral public key and calculates bP a = baG. Thus, Alice and Bob now share a secret key k ab = abG which they can use to secure a communication channel either on the block chain, or on a channel outside the block chain. This shared key can in particular make it possible to ensure the confidentiality of data or be used for authentication purposes.
    Note that the amounts @ wallet_Bob-amount and @ wallet_Alice-amount can be chosen equal, so that the cost of the exchange is zero or very low (limited to transaction costs or transaction fees for mining).
    Those skilled in the art will understand that the exchange of keys illustrated in FIG. 2 does not require the intervention of a trusted third party. The auditability of the registry by the users of the blockchain allows each of them to verify that the ephemeral public keys used during this process have never been used before, that the public key P a belongs to Alice ( more precisely is linked in a one-to-one way to Alice's wallet address) and that the public key P b belongs to Bob (more precisely is linked in a one-to-one way to Bob's wallet address). Because of this auditability, the exchange of keys is protected from a Man-ln-the-Middle attack.
    Finally, it is essential to note that unlike the prior art cited in the introductory part, the exchange of keys does not require the creation of ephemeral wallets but is content to use the existing Alice and Bob wallets .
    权利要求:
    Claims (6)
    [1" id="c-fr-0001]
    1. Method for exchanging keys between a first user and a second user of a chain of transaction blocks, each user having a wallet address enabling him to send and receive transactions, characterized in that:
    the first user generates (210) a first ephemeral private key (a) and a first ephemeral public key (corresponding PJ by means of an asymmetric cryptosystem;
    the first user forms and issues (220) a first transaction (T A ), the input of which refers to a first UTXO held at the portfolio address of the first user and the output of which creates a second UTXO in the portfolio of the second user , the output of the first transaction further comprising a script for registering the first ephemeral public key (P a ) in the block chain;
    the second user scans (230) the block chain and accesses the first transaction, after it has been confirmed by a mining of the block which contains it;
    the second user verifies from the entry of the first transaction that it has been issued by the address of the wallet of the first user and, if so, reads on the output of the first transaction the first public key ephemeral ( p J;
    the second user generates (240) a second ephemeral private key (b) and a corresponding second ephemeral public key (P b ) using said asymmetric cryptosystem;
    the second user forms and issues (250) a second transaction (7 ^) whose input refers to a third UTXO held at the wallet address of the second user and whose output creates a fourth UTXO pointing to the wallet of the first user , the output of the second transaction further comprising a script for registering the second ephemeral public key in the blockchain;
    the first user scans (270) the blockchain and accesses the second transaction, after it has been confirmed by a mining of the block which contains it;
    the first user verifies from the entry of the second transaction that it has indeed been issued by the address of the wallet of the second user and reads on the output of the second transaction the second ephemeral public key (P b );
    the first user calculates (280) the product of the first ephemeral private key (a) with the second ephemeral public key () and the second user calculates (280) the product of the second ephemeral private key (b) with the first public key ephemeral (P a ) to generate a common secret key (k ab ).
    [2" id="c-fr-0002]
    2. A key exchange method according to claim 1, characterized in that:
    the first transaction contains as input an unlocking script comprising the public key associated with the wallet address of the first user as well as a digital signature of this public key by means of the first ephemeral private key;
    - The second transaction contains as input an unlocking script comprising the public key associated with the wallet address of the second user as well as a digital signature of this public key by means of the second ephemeral private key.
    [3" id="c-fr-0003]
    3. A key exchange method according to claim 1 or 2, characterized in that the asymmetric cryptosystem is a cryptosystem on an elliptical curve.
    [4" id="c-fr-0004]
    4. A key exchange method according to claim 3, characterized in that the block chain is Bitcoin and that the script for recording the first and second transactions contains an OP_RETURN operation, the first and second ephemeral public keys being stored by the recording script in compressed form in the blockchain.
    [5" id="c-fr-0005]
    5. A key exchange method according to claim 3, characterized in that the block chain is Bitcoin and that the first and second transactions comprise as output a second recording script, the recording script and the second script d record containing OP_RETURN operations, first and second keys
    5 ephemeral public ones are respectively stored by the recording script and the second recording script in complete form in the block chain.
    [6" id="c-fr-0006]
    6. A key exchange method according to one of the preceding claims, characterized in that the amounts of the first and third UTXO are identical.
    1/2
    S.63090
    Alice bob
    2/2 o m CM o
    CM
    Alice Bob c O P ra (ZI c
    OJ 'OJ
    E
    4 =
    VS
    O <J
    Λ o _Q £ 0 o Φ CQ at · 4-Φ E o ω u § © J
    CM
    Σ1
    φL- O O Π3 + -> L- M- ΟΊ OJ VS ’ÙO OJ L— O vs Φ u L- Q. 'ra Φ X _vs VS OJ o 5 c ra o _x(J o _x o O + · U Φ —1 CD _Q ^ _Q
    o
    CM
    CM aj 'OJ E L— u = c o (J
    ΦL- O O Λ + -> · L - M- ΟΊ Φ VS ’ÙO Φ L · o vs Φ u L- Ο- 'ra Φ χ _vs VS Φ o 5 c ra o _x(J o _x o O + · U Φ —1 (S) _Q _Q
    o LO CM
    Q.
    d φ ~ o ra
    O
    CM
    Fig. 2
    FRENCH REPUBLIC
    National registration number
    FA 851651
    FR 1763393 irai - I NATIONAL INSTITUTE
    PROPERTY
    INDUSTRIAL
    PRELIMINARY SEARCH REPORT based on the latest claims filed before the start of the search
    EPO FORM 1503 12.99 (P04C14)
    DOCUMENTS CONSIDERED AS RELEVANT Relevant claim (s) Classification attributed to the invention by ΙΊΝΡΙ Category Citation of the document with indication, if necessary, of the relevant parts XAT MCCORRY PATRICK ET AL: Authenticated Key Exchange over Bitcoin,December 9, 2015 (2015-12-09), MEDICAL IMAGE COMPUTING AND COMPUTER-ASSISTED INTERVENTION - MICCAI 2015: 18TH INTERNATIONAL CONFERENCE, MUNICH, GERMANY, OCTOBER 5-9, 2015; PROCEEDINGS; [READ NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CH, ΧΡΘ47412487, ISSN: 0302-9743ISBN: 978-3-642-16065-3 [extracted on 2015-12-09]* abbreviated ** page 8; table 1 ** page 9; figure 2 ** Section 3.3 Diffie-Hellman-over-Bitcoin Protocol;page 10 *Tatsuya Kyogoku ET AL: A Note on Authenticated Key Exchange in Cryptocurrency,2016 Symposium on Cryptography and Information Security (SCIS 2016),January 22, 2016 (2016-01-22), pages 19-22, XP055497256,Extract from the Internet:URL: https: //security-kouza.github.io/paper /SCIS2016_kyogoku.pdf[extract 2018-08-03]* abbreviated ** Chapter 4: Protocol <Pi>; page 4, left column *- / - 1-61-6 H04L9 / 08 TECHNICAL AREAS SOUGHT (IPC) H04L Research Completion Date ExaminerAugust 6, 2018 Di Felice, M CATEGORY OF DOCUMENTS CITED T: theory or principle underlying the inventionE: patent document with an earlier date X: particularly relevant on its own at the filing date and which was not published until that dateY: particularly relevant in combination with a deposit or at a later date.other document of the same category D; cited in requestA: technological background L: cited for other reasonsO: unwritten disclosureP: interlayer document &: member of the same family, corresponding document
    page 1 of 2
    FRENCH REPUBLIC
    National registration number
    FA 851651
    FR 1763393 irai - I NATIONAL INSTITUTE
    PROPERTY
    INDUSTRIAL
    PRELIMINARY SEARCH REPORT based on the latest claims filed before the start of the search
    EPO FORM 1503 12.99 (P04C14)
    DOCUMENTS CONSIDERED AS RELEVANT Relevant claim (s) Classification attributed to the invention by ΙΊΝΡΙ Category Citation of the document with indication, if necessary, of the relevant parts ATAT BUI THANH ET AL: Key Exchange with the Help of a Public Ledger,November 29, 2017 (2017-11-29), MEDICAL IMAGE COMPUTING AND COMPUTER-ASSISTED INTERVENTION - MICCAI 2015: 18TH INTERNATIONAL CONFERENCE, MUNICH, GERMANY, OCTOBER 5-9, 2015; PROCEEDINGS; [READ NOTES IN COMPUTER SCIENCE; LECT.NOTES COMPUTER], SPRINGER INTERNATIONAL PUBLISHING, CH, ΧΡΘ47455716, ISSN: 0302-9743ISBN: 978-3-642-16065-3 [extracted on 2017-11-29]* abbreviated ** Chapter 4: Public-Ledger-Based Key Exchange;pages 128-131 *P Sivakumar ET AL: Privacy based décentraiized Public Key Infrastructure (PKI) implementation using Smart contract in Blockchain,2nd Advance Workshop on Blockchain: Technology, Applications, Challenges,December 17, 2017 (2017-12-17), pages 1-6, XP55497247,Extract from the Internet:U RL: https: //isrdc.i itb.ac.in/blockchain/wo rkshops / 2017-ii tb / papers / paper-ll% 20-% 20De centrali zed% 20PKI% 20i n% 20blockchai n% 20and% 20Smart % 20contract.pdf [extracted on 2018-08-03]* abbreviated ** Chapter 3: Proposai: Décentraiized PKI with privacy in Blockchain;pages 3-5 ** Chapter 4: Implementation; pages 5-6 * 1-61-6 TECHNICAL AREAS SOUGHT (IPC) Research Completion Date ExaminerAugust 6, 2018 Di Felice, M CATEGORY OF DOCUMENTS CITED T: theory or principle underlying the inventionE: patent document with an earlier date X: particularly relevant on its own at the filing date and which was not published until that dateY: particularly relevant in combination with a deposit or at a later date.other document of the same category D; cited in requestA: technological background L: cited for other reasonsO: unwritten disclosureP: interlayer document &: member of the same family, corresponding document
    page 2 of 2
    类似技术:
    公开号 | 公开日 | 专利标题
    US10652014B2|2020-05-12|Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys
    EP3259724B1|2021-03-24|Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system
    EP3506557B1|2020-07-01|Method of key exchange via a smart contract deployed over a blockchain
    EP3506556B1|2020-08-05|Method of authenticated key exchange via blockchain
    FR2958101A1|2011-09-30|PHYSICAL SECURITY BI-KEY MANAGEMENT INFRASTRUCTURE |
    EP2345202B1|2017-04-05|Digital signature method in two steps
    CN111783136A|2020-10-16|Data protection method, device, equipment and storage medium
    FR3044499A1|2017-06-02|METHOD OF ESTABLISHING SECURE END-TO-END COMMUNICATION BETWEEN A USER TERMINAL AND A CONNECTED OBJECT
    US20160080336A1|2016-03-17|Key Usage Detection
    Boyen2010|Identity-based signcryption
    EP3211826B1|2019-06-12|Method for handling implicit certificates using a distributed public key infrastructure
    CA2831167C|2020-06-02|Non-hierarchical infrastructure for managing twin-security keys of physical persons or of elements |
    WO2007042419A1|2007-04-19|Cryptographic method using an identity-based encryption system
    WO2014154694A1|2014-10-02|Group signature using a pseudonym
    Rahim2019|A Review on Cryptography Protocol for Securing Data
    FR3102024A1|2021-04-16|A method of managing a public key database, a method of authenticating public keys, and server and client devices implementing these methods
    WO2021133153A1|2021-07-01|Transaction signing with ergonomic addressing and compact encapsulation
    Shahi et al.2013|To Secure and Compress the Message on Local Area Network
    同族专利:
    公开号 | 公开日
    US20190207757A1|2019-07-04|
    EP3506556A1|2019-07-03|
    FR3076422B1|2020-09-25|
    EP3506556B1|2020-08-05|
    US10985910B2|2021-04-20|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20170228731A1|2016-02-09|2017-08-10|Fmr Llc|Computationally Efficient Transfer Processing and Auditing Apparatuses, Methods and Systems|
    US10067810B2|2016-07-28|2018-09-04|Cisco Technology, Inc.|Performing transactions between application containers|US11245516B2|2019-04-24|2022-02-08|Veridify Security Inc.|Shared secret data production with use of concealed cloaking elements|
    CN110602694B|2019-09-16|2021-03-23|广州大学|User privacy protection crowd sensing system based on block chain|
    CN112633847B|2020-12-29|2022-01-04|因特睿科技有限公司|Processing method, processing device and processor for government affair information resources|
    法律状态:
    2018-12-31| PLFP| Fee payment|Year of fee payment: 2 |
    2019-07-05| PLSC| Search report ready|Effective date: 20190705 |
    2019-12-31| PLFP| Fee payment|Year of fee payment: 3 |
    2020-12-28| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1763393|2017-12-29|
    FR1763393A|FR3076422B1|2017-12-29|2017-12-29|BLOCK CHAIN AUTHENTICATED KEY EXCHANGE METHOD|FR1763393A| FR3076422B1|2017-12-29|2017-12-29|BLOCK CHAIN AUTHENTICATED KEY EXCHANGE METHOD|
    EP18215897.2A| EP3506556B1|2017-12-29|2018-12-26|Method of authenticated key exchange via blockchain|
    US16/233,974| US10985910B2|2017-12-29|2018-12-27|Method for exchanging keys authenticated by blockchain|
    [返回顶部]